上一篇我們介紹了 PostHog 的 Survey，可以直接在產品中向使用者取得回饋。

這類工具最大的優點是成本低。問卷設定完成後，就可以持續向符合條件的使用者詢問問題，不需要每次都安排人工訪談。

例如我們可以在使用者放棄購買後詢問：

剛才沒有完成購買的原因是什麼？

使用者可能回答：

我不確定這雙鞋的尺寸，所以先沒有買。

這已經比單純看到 purchase_completed = false 多了很多資訊。

但有時候，這個回答反而會帶來更多問題：

他缺少的是什麼尺寸資訊？

原本有沒有在網站裡找？

如果沒有找到，後來去了哪裡？

最後有沒有在其他地方完成購買？

我們當然可以繼續修改 Survey，加入更多問題。不過 Survey 的問題通常需要事先設計好，如果使用者突然提到一件完全出乎預期的事情，我們很難像真正的對話一樣，立刻沿著這條線索繼續深入。

這時候，我們可以暫時離開 PostHog，使用另一種產品研究方法：使用者訪談（User Interview）。

Survey 和 Interview 取得的都是使用者回饋，但適合處理的問題並不完全相同。

Survey 的問題通常在送出去以前就已經大致決定，因此很適合低成本地向大量使用者取得相對結構化的資訊。例如我們已經懷疑「一鍵下單容易誤觸」，就可以透過 Survey 了解有多少使用者遇過，以及通常發生在什麼情境。

Interview 則更適合深入探索。使用者回答了什麼，會直接影響我們下一個問題要問什麼。如果訪談中突然出現原本完全沒有想到的資訊，我們可以暫時放下原先準備的問題，沿著新的線索繼續追問。

不要讓使用者替你設計產品

談到使用者訪談，有一句經常被歸於 Henry Ford 的名言：

如果我問人們想要什麼，他們會說更快的馬。

這句話是否真的出自 Ford 沒有可靠的證據，但它背後的概念很值得討論。

如果十九世紀的人需要更快速地移動，而我們直接問：

你希望我們做什麼？

那麼「更快的馬」其實是個很合理的答案。

因為使用者通常會從自己已經知道的 Solution 出發。他知道馬可以移動，所以自然想到讓馬跑得更快，而不是突然提出汽車。

但這並不代表我們不應該聽使用者的。

真正值得了解的是：

你為什麼需要一匹更快的馬？

答案可能是：

我每天需要花兩個小時從家裡前往工作地點，希望縮短通勤時間。

這時候，「更快的馬」消失了，留下的是問題本身。

這其實和前面介紹 Job Story 時的概念很相似。我們真正關注的是使用者想取得什麼進展，而不是要求使用者替我們指定 Solution。

因此，如果我們正在考慮在商品頁面加入聊天室，直接問：

如果我們加入聊天室，你會使用嗎？

通常很難得到可靠的資訊。

首先，這要求使用者預測未來的自己。使用者現在可能真心覺得：

聽起來滿方便的，我應該會用。

但功能真的上線之後，他可能根本想不起來聊天室存在，也可能發現自己還是習慣去 Google、Reddit 或直接問朋友。

另一方面，這個問題也已經把 Solution 限定成「聊天室」。即使真正需要解決的是「取得其他買家的經驗」，我們也提前縮小了解法的範圍。

比起詢問假想的未來，更有價值的方式通常是從真正發生過的事情開始。

例如：

你上一次因為不確定商品適不適合自己，而沒有購買是什麼時候？

接著沿著這段經歷繼續詢問：

當時缺少什麼資訊？

後來怎麼找這些資訊？

最後有找到嗎？

最後為什麼決定買或不買？

假設使用者回答：

我去 Reddit 找其他人的心得。

這時就可以繼續問：

為什麼選 Reddit？

使用者可能進一步說：

因為我不太相信商品頁面上的評論。

到這裡，問題可能已經和我們一開始想的不一樣了。

原本我們以為問題是「缺少和其他買家溝通的方式」，後來可能發現真正的問題包含「無法快速找到和自己情況相似的評論」，甚至是「不信任網站內的評論」。

這些資訊不一定能在訪談前全部預測出來。

也許最後我們仍然會決定建立聊天室；也可能發現商品評論其實已經足夠，只是搜尋功能太差；或者真正需要的是把大量評論整理成摘要；甚至可能發現使用者根本不信任網站內的評論，那麼再打造一套聊天室也不見得能解決問題。

訪談的目的不是請使用者告訴我們該開發什麼，而是讓我們更清楚：真正值得解決的是什麼問題。

工程師怎麼取得訪談機會？

講到這裡，對工程師來說可能還有一個更現實的問題：

我要去哪裡找使用者？

對產品經理、UX Researcher 或 Customer Success 來說，接觸使用者可能本來就是工作的一部分。但工程師通常離這些流程比較遠，要突然要求公司安排幾名客戶接受訪談，未必是一件容易的事情。

在《The Product-Minded Engineer》中也提到，對工程師而言，取得訪談機會本身往往就是最困難的一步。

最簡單的方法，不一定是自己從零開始安排一場正式的 User Interview，而是先加入公司原本就存在的使用者接觸管道。

例如 PM、UX Researcher、Customer Success、Sales、Account Manager、Solution Architect 等角色，本來就可能定期和客戶開會。這時候可以先詢問能不能旁聽，甚至只是在會議最後留下幾分鐘，詢問幾個和目前開發內容有關的問題。

如果平常有參與 Support，也是一個很自然的入口。

假設某個使用者回報匯出功能有問題，我們協助處理完後，可以再詢問：

我們最近也在改善這個流程，如果方便的話，我想再了解一下你平常怎麼使用這個功能。

因為雙方已經有了實際互動，而且剛剛才協助對方解決問題，使用者通常也比較容易願意提供更多資訊。

上一篇介紹的 PostHog Survey 也可以拿來尋找願意進一步溝通的使用者。

例如在問卷最後詢問：

如果我們想進一步了解你的使用經驗，是否願意讓我們透過 Email 聯絡？

這樣就可以先透過 Survey 找到真正遇到特定問題、又願意提供更多資訊的人，再另外聯絡並安排訪談。

因此，工程師不一定需要自己建立一套完整的 User Research 流程。很多時候，更實際的作法是加入團隊原本就存在的使用者接觸點，逐漸建立取得第一手資訊的管道。

真的取得訪談機會後，也不需要把自己想像成專業的研究員。

訪談前可以先準備幾個想了解的方向，但不需要把問題當成一定要照順序問完的清單。使用者提到值得深入的地方時，可以沿著回答繼續追問，了解事情發生的情境、原因與結果。

比起詢問抽象看法，優先詢問近期真正發生過的事情；比起急著提供解法，先讓使用者把經歷說完整；如果回答中出現意料之外的資訊，也不要急著拉回原本準備的問題。

另外也要避免把自己的判斷塞進問題裡。例如使用者說某個操作很麻煩，可以繼續問「哪個地方讓你覺得麻煩？」，而不是直接猜測「是不是因為欄位太多？」。

訪談的重點不是把所有問題問完，而是盡可能還原使用者當時想完成什麼、遇到了什麼問題，以及最後怎麼處理。

得到這些資訊後，也不代表 Alice 說想要 Apple Pay，我們就馬上建立一張 Apple Pay 的開發票。

單一使用者的回答仍然只是證據的一部分。我們可以把不同訪談、Survey、Product Analytics 等資訊放在一起觀察，找出反覆出現的情境與問題，再形成新的假設、提出 Solution，最後回到前面介紹的開發與驗證循環。

在系列一開始介紹產品工程師時，我們提過其中一個重要特徵：產品工程師會直面真實的使用者。

這並不是要求工程師取代 PM、Customer Success 或 UX Researcher，而是避免工程師只能透過需求單認識使用者。

一段真實的使用情境可能是：

使用者結帳時經常需要離開頁面尋找地址，回到網站後原本輸入的內容會消失，因此常常放棄購買。

這種資訊會直接影響工程師怎麼理解問題、怎麼評估需求，以及最後怎麼設計與驗證解法。

下一篇開始，我們會進入 AI 產品的部分。AI 功能也一樣需要被測試與驗證，只是它多了一個麻煩：程式沒有報錯，不代表答案就是對的。

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見